Jukeboxes have been around for decades and provide users with the ability to select desired music for reproduction in a convenient and advantageous manner. Jukeboxes have conventionally been provided in commercial establishments, such as restaurants and bars, in order to provide desired music on demand for patrons thereof for a fee. Over the last several years, a new generation of jukebox devices have become available that provide significant improvements in the operation thereof for all parties involved. More specifically, the conventional standalone phonorecord and CD jukeboxes are being replaced by digital downloading jukeboxes that are controlled by and communicate with a central server. An example of this new generation jukebox system is shown in U.S. Pat. No. 6,308,204, the disclosure of which is incorporated by reference herein in its entirety. A leading provider of this new generation of jukebox systems is TouchTunes Music Corporation.
FIG. 1 shows an overview of an exemplary embodiment of a digital downloading jukebox system 10 (hereinafter referred to simply as a “jukebox system”). As shown in FIG. 1, the jukebox system 10 includes a central server 12 that contains a master library of audio content (typically music), as well as or alternatively audiovisual content (typically music and associated video or graphics), that can be downloaded therefrom. The jukebox system also includes a series of remote jukebox devices 16, 16a-16f. Each of these jukebox devices are generally located in a bar, restaurant, club or other desired location, and are operable to play music in response to receiving a payment from a user, such as coins, bills, credit/debit card, etc., and having one or more songs selected by the user for play. In an alternative embodiment, a music service is paid for on a subscription basis by the location, and the selected music is free for the end-user. The jukebox device 16 typically includes a screen 18 that presents information to the user and allows the user to select songs therefrom, as well as an audio system 20 that plays the selected songs. The screen 18 may also be used for displaying song-related video or graphics. The screen 18 may also be used to display advertisements for the jukebox itself in order to attract customers thereto, to display other types of advertisements and/or to display any other desired information.
The jukebox devices 16 (sometimes referred to as simply “jukeboxes” herein) are operable to communicate with the central server 12 through a communications network 14, such as, for example, the Internet. The jukeboxes 16 periodically communicate with the server 12 in order to provide information to the server 12 regarding the specific songs that have been played on the jukebox. The central server then uses this information in order to determine the appropriate royalties and/or other payments that are owed for songs played on each jukebox. Thus, one significant advantage of this new generation of jukeboxes is that the sound reproduction and/or other applicable music rights can be adhered to in a more accurate and reliable manner, thereby assuring the proper royalties are paid to the artists or music owners. The central server 12 can also provide new songs to the jukebox 16 in order to assure that the appropriate or most popular songs are maintained on the jukebox based on the specific customers at that location. Thus, the songs available on each jukebox can be customized through communication with the central server in order to provide the songs and/or types of music that customers generally request at each jukebox location. As described in the above-referenced U.S. Pat. No. 6,308,204, the central server can also advantageously be used to update the operating software on the jukeboxes in order to, for example, change the operation of the jukebox, such as to provide new or improved features. Thus, another significant advantage of this new generation of jukeboxes is that the songs (or other audio and/or visual content), and the operation of the jukebox itself can be remotely changed as desired without the need to have someone (such as a routeman) personally service the jukebox. Instead, such updates can be done using the central server 12.
As indicated above, the jukebox devices 16 each include a mass storage device, such as a hard drive, which stores the songs and associated video/graphics data (if any), as well as any other desired graphical information for reproduction on the jukebox. The mass storage device of the jukebox typically has limited storage capacity relative to the storage device of the central server 12. As a result, only a fraction of the songs stored on the central server are actually stored on the mass storage device of the jukebox at any one time. There may be other reasons as well, such as for security of the data or limited room in the jukebox itself, for having limited storage capacity on the jukebox and/or limiting the number of songs stored thereon. For example, physical space may be limited on wall-mount jukeboxes or the like, which are designed to be small in size as compared to free standing models. As explained above, the songs on the jukebox can be changed through communication with the central server, but any one jukebox only stores a subset of the complete library of songs maintained by the central server at any one time.
In order to maximize the revenue that a jukebox generates it is important to make the most desired songs available on the jukebox over time. If customers cannot find songs they like on the jukebox, usage of the jukebox (and the revenue generated thereby) will dramatically decrease. On the other hand, it is impossible to predict in advance exactly what a customer at any particular location will desire to play on the jukebox. In fact, there are likely many instances where a customer would have selected a song that exists on the central server but is not currently present on the jukebox. As a result, the jukebox may not be enjoyed and used to its fullest extent. In order to address this problem and increase revenue, jukebox systems have in the past provided a feature which enables the user to search for songs on the central server from the jukebox and request an immediate download of a desired song from the central server to the jukebox for an additional fee. This feature enables the user to play any song in the master library of songs maintained by the central server using the jukebox, regardless of whether or not the specific song is presently stored in the mass storage of the jukebox itself. Thus, the user can first look for desired songs on the local storage of the jukebox and then, if desired, search further on the central server for desired songs. The jukebox device typically charges an additional fee (such as five credits instead on one credit) for an immediate download and play of a song from the central server as opposed to a standard play directly from the jukebox's local storage.
One problem, however, with the immediate downloading feature is that it is desirable to have an immediate and high speed connection with the central server to implement. In addition, the central server and network must be prepared to and capable of handling such requests in a reliable and efficient manner for the feature to properly operate. These requirements cannot always be met and, as a result, implementation of this feature has been limited. For example, many locations that have jukeboxes do not have high speed connections (such as DSL) and instead use dial-up modem connections. Jukeboxes which rely on dial-up connections generally are only designed to communicate with the server periodically and do not allow the user to immediately download a song. They have, however, enabled a user to vote for a song to be downloaded at a later time when the dial-up connection is made. This, of course, is not as satisfying to the user as being able to immediately download a song. Other problems can arise in connection with this download feature if the network or server is not currently available for the download, due to traffic, malfunctions or the like.
For the reasons explained above, there is a need for a jukebox system that overcomes these and other disadvantages. The instant invention is designed to address these and other problems and to provide even further functionality for such jukebox systems.
In accordance with an exemplary aspect of the instant invention, a local content server is provided for each jukebox in the jukebox system. The local server preferably mirrors the master library of songs (and/or other content) on the central server. The local server is installed in close proximity to the jukebox to which it is assigned and preferably in the same restaurant or bar where the jukebox is installed. The local server may even be installed within the housing of the jukebox device itself if space permits. Preferably, however, the local server is simply installed in a convenient location and connected to the jukebox using a high speed connection, such as, for example, Ethernet or the like. In accordance with an exemplary embodiment, the local server is used to implement the immediate downloading feature described above without the need for a high-speed connection with the central server. In other words, the user can first search the local storage on the jukebox for desired songs and then, if desired, search further on the local server for desired songs. If the desired song is found on the local storage it is played from the local storage for a normal fee. On the other hand, if the song is only found on the local server, the song can be immediately downloaded, at the option of the user, from the local server to the jukebox for playing for a fee that is preferably higher than the normal fee. As a result, the immediate downloading feature can be reliably implemented regardless of the connection type to the central server and regardless of the availability of the network or the central server. Moreover, because the download comes from the local server rather than the central server is transparent to the user.
Alternatively, in another exemplary aspect, a jukebox is provided with locally-attached expanded storage media. While not as large as the server drive in the above preferred embodiment, the storage media may, in one embodiment, hold approximately 20% of the songs available on the central server. Studies have shown that the song group comprising approximately the top 20% of the most requested songs will satisfy the play requests of approximately 80% of the end users. In another exemplary embodiment, this media may hold approximately 30% of the songs available on the central server, which correlates to the requests of approximately 90% of the end users. The amount of song data stored on the media can be any suitable amount to accomplish the desired functionality. For example, if new data indicates that only 10% of the songs need to be stored, then that would be an appropriate amount to store.
In accordance with another exemplary aspect of the invention, the local server or storage media is periodically updated with data (e.g., songs) to correspond with the contents of the master library of data (e.g., songs). The updating may occur remotely using dial-up or broadband connections, or it may be updated manually by, for example, an operator using an update tool provided by the entity controlling the jukebox system which can be directly connect to the jukebox or local server for the purpose of updating the local server or storage media so that the contents correspond to the master library on the central server, or so that the contents at least correspond to the current desired percentage of the most selected songs.
In accordance with another exemplary embodiment, the server includes an array of hard drives with associated IDE controller(s), a microprocessor, a flash memory containing the BIOS and the operating system, RAM and an Ethernet controller for communication with the jukebox. Each local server is preferably assigned or registered to the specific jukebox to which it is connected. For security purposes, the data on the local server preferably does not comprise any complete songs. Instead, the jukebox device includes missing data from each song on the local server, so that the jukebox can construct the entire song from the contents of its storage device and the contents of the local server. The data on the local server is also preferably encrypted using the missing data (e.g., one block), thereby preventing songs from being copied or played from the local server by any device other than the jukebox to which it is assigned.
In accordance with another exemplary aspect of the invention, a collection of local servers may be used as a network of distributed servers which can be controlled by the central server to provide music services to other devices which are connectable to the network through which the central server and jukeboxes communicate. For example, the local servers and associated jukebox are used to deliver any requested song to a dedicated residential or commercial jukebox device (or other suitable jukebox device) in addition to providing song services to the specific jukebox to which it is connected and assigned.
In accordance with a further exemplary aspect of the invention, the local server and jukebox device are used, under control of the central server, to provide management services for other types of coin operated or payment triggered equipment, such as gaming devices, installed in the same location as the jukebox. In other words, the jukebox system is preferably used to update the functionality of and/or manage other downloading devices present in the same location. As a result, the jukebox functions as a “central hub” for all downloading equipment in a location. This feature is achieved, in one embodiment, by networking all of the downloading devices in a single location together with the jukebox and local file server. The central server can then download information to the local server together with instructions to the jukebox as to which devices should be updated with what data and/or software. The jukebox device and local server can also be used to collect information from the other downloading devices to which it is managing and upload that information to the central server for reporting/accounting purposes. Thus, the owner/operator of the jukebox system can act as a third party service provider to other coin-op companies for the purpose of managing and/or updating their equipment, such as electronic gaming equipment.
In accordance with an additional exemplary aspect of the illustrative embodiments, the jukebox has, or is given, the processing power to play multiple songs simultaneously through different outputs to different zones. In a preferred embodiment, an establishment containing three zones: a restaurant, a bar, and a pool room, can have a number of selections, up to the number of zones or speaker outputs, playing at the same time. This allows for increased revenue in the jukebox system, as patrons of any one zone can listen to a selected song at the same time as patrons of another zone listen to a different song.
In accordance with a further exemplary aspect of the illustrative embodiments, the user may select a song to play in more than one zone of the establishment. This play may be simultaneous in the multiple zones, or may occur at different times. This allows the jukebox operator to capture additional revenue for playing the same song more than once, and potentially an even greater amount of revenue for guaranteeing that the song is played simultaneously in multiple zones of the establishment.
In accordance with another exemplary aspect of the illustrative embodiments, each zone is provided with a terminal which allows patrons in that zone to select songs for play on the jukebox. In a preferred embodiment, the terminal is a “dummy” terminal, provided with a graphical user interface (GUI) for song selection, however a gaming terminal or any other suitable device capable of providing a GUI may be used.
In accordance with an additional exemplary aspect of the illustrative embodiments, the operator can restrict the selections that can be played in a given zone. For example, in a restaurant zone of a multi-zone establishment, the operator may desire to restrict music to that suitable for a dining atmosphere. The operator can also restrict or allow other aspects of selection play in each zone, such as volume, priority play availability, etc.
In accordance with a further exemplary aspect of the illustrative embodiments, the jukebox may be provided with an algorithm or other method to selectively select background music, based on the zone, the time, or any other suitable criteria.
In accordance with another exemplary aspect of the illustrative embodiments, the different zones may be provided with independent priority and non-priority play queues.
In accordance with an additional exemplary aspect of the illustrative embodiments, jukeboxes with expanded song storage capability may provide only a subset of the total songs stored as the basic available songs. If a user desires a song that is not a member of the provided subset, the user may pay extra to have the song played. If the song is stored in the larger master set on the expanded storage capacity, the song can be queued up immediately, without the need for download, allowing users faster access to an expanded song selection. Even if the song is not available on the expanded list, the user may order the song, and if suitable conditions, such as a high speed connection, exist, the user may hear the song almost immediately. Alternatively, the song may be downloaded and saved for the user to select at a later date or time, such as, for example, when the jukebox is connecting in dial-up mode and needs to download the songs at a later time.
In accordance with another exemplary aspect of the illustrative embodiments, the jukebox can be set to “customize mode,” where users can use an interface to select songs that will be transferred from the local server or expanded media storage to the jukebox or jukebox set. This mode could be used, for example, by regular users or customers and location staff to specify which songs should permanently reside on the jukebox after a jukebox is newly installed in a location.
In accordance with a further exemplary aspect of the illustrative embodiments, a jukebox can “morph” based on a triggering event. Triggering events can include themed establishment nights, time changes, or any other suitable criteria. When the jukebox morphs, it may provide a wholly or partially different subset of available songs for user selection at normal cost. Additionally, since the interface is a digital one, new graphics, advertising or other suitable display changes may occur, in accordance with the morph. The morph may also selectively block all access to certain songs, based on the appropriateness of the song under the criteria which caused the morph. For example, if an establishment had a “country night,” then the available songs might shift to all country songs. The jukebox might further block expanded access to all songs that were not defined as appropriate for a “country night,” so that such blocked songs were not even available for play at an increased price until the morph had expired. The definition of “appropriate songs” can be a factory set definition, or can be definable by the operator of the jukebox or by any other suitable classification mechanism.
In accordance with another exemplary aspect of the illustrative embodiments, different terminals of a multi-zone system can morph independently of each other, so that, for example, a bar zone may morph after a certain hour while a restaurant zone may remain the same.
In accordance with an additional exemplary aspect of the illustrative embodiments, a user can bid on the right to have a song played before other songs previously selected for priority play are played. In a preferred embodiment, the user is shown the top price paid for a priority play, and can pay more than that price to obtain the highest priority available.
In accordance with a further exemplary aspect of the illustrative embodiments, a user may not be shown how much anyone else has paid for priority. The user can pay however much the user desires to spend to obtain a priority ranking, and then receive a ranking of priority based on the amount paid.
In accordance with another exemplary aspect of the illustrative embodiments, a user can pay however much the user desires to spend to obtain a priority ranking, and then be shown the priority spot which has been obtained based on the paid amount. If this spot is not satisfactory to the user, the user can pay additional money to move the song up in priority ranking. The user can also pay additional money to make it harder for other users to pre-empt the selected priority spot on the list in a bidding-type situation. Any other suitable method of increased-pay-for-increased-priority may also be implemented.
In accordance with a further exemplary aspect of the illustrative embodiments, a user can “lock in” a priority ranking with a payment of a pre-selected amount. For example, if a user pays 15 credits to obtain a ranking of 3rd in priority, and wishes to guarantee the third ranking, the user may pay, for example, 4 more credits to “lock in” the ranking. Since locking in the ranking may require the “lock in” of all the rankings above the user as well, the user may be required to pay a certain amount to “lock in” all songs above the user's selection. In one such situation, the user can either choose to pay the price quoted for the “lock in” or pay the same or a varying amount of credits in an attempt to prevent future over-bidding or to move the user's song up further in the priority list.
In accordance with another exemplary aspect of the illustrative embodiments, any of the aforementioned bidding strategies may be implemented, and the user may be shown how much everyone has paid for their particular rankings. This allows the user to know exactly how much he will have to pay to obtain a certain priority position. If the “lock in” feature is implemented, this will also let a user know if it is cheaper to pay the price to “lock in” the song or to pay to move up on the priority list. All of these options result in increased revenue for the operator.